Long Term Evolution (LTE) is a communication network technology currently under development by the 3rd Generation Partnership Project (3GPP). LTE requires a new radio access technique termed Evolved Universal Terrestrial Radio Access Network (E-UTRAN), which is designed to improve network capacity, reduce latency in the network, and consequently improve the end-user's experience. System Architecture Evolution (SAE) is the core network architecture for LTE communication networks.
LTE uses exclusively packet switched (PS) signalling. When a network operator wishes to introduce LTE, he will be unable to operate a complete LTE service from the first day. LTE will need to be rolled out gradually to replace existing technologies. In order to do this, LTE networks must have some way of interacting with networks that use other technology, such as circuit switched (CS) signalling. Single Radio Voice Call Continuity (SRVCC), described in 3GPP TS 23.237 and 3GPP TS 23.216, allows handover of a session from an LTE network to a CS network.
Referring to FIG. 1, there is illustrated a scenario in which a User Equipment (UE) 1 has an established LTE bearer with ongoing speech session over an IP Multimedia Subsystem (IMS) in a location 2 with LTE coverage. The UE 1 then moves to a second location 3 in which LTE coverage is no longer available, but a legacy CS network provides coverage. The LTE network communicates with a Mobile Switching Centre (MSC) Server 4 to indicate that the session is to be handed over from the LTE network to the CS network. The MSC server 4 notifies the IMS network 5 of the handover. The IMS network then ensures that the session can be handled by the CS network.
Similarly, handover can take place from UTRAN (HSPA) using IMS to a CS access. In the below description, the example of LTE is used, but can be replaced with HSPA.
A problem arises when, for example, a video call is to be transferred from the LTE network to a PS network. The access network is not aware that the call to be moved from PS to CS access is a video call, and so the access network cannot identify a difference between bearers used when setting up the call to carry video from a video call, or bearers used for other video applications, such as a video sharing application or a Mobile TV session.
One suggestion (described in 3GPP TR 23.886v0.3.1) for video call SRVCC assumes that the access network can determine that a video call is taking place by looking at the bearers that have been established. Each bearer is assigned a Quality of Service Class Identifier (QCI) depending on the type of media that is being transported by the bearer. If one bearer with QCI=1 (indicating voice) and another bearer with QCI=2 (indicating video) exist, then it is assumed that the call is a video call, and should be transferred as such.
A problem with this solution is that is restricts the usage of existing bearers. While QCI=2 is typically used for the video component of a video call, QCI=2 can be used for other types of video, so requiring that QCI=2 is only used for video calls creates problems with backward compatibility with existing terminals and applications that may use QCI=2 for video uses other than video calls. Furthermore, the described in 3GPP TR 23.886v0.3.1 implies that only one bearer can use QCI=2. This is because video may be streamed using different applications, each using QCI=2, and there is no way of knowing from QCI=2 which bearer relates to the video call.
A further problem is that operators may wish to use QCI values other than 2 for video calls. For example, a network operator might wish to reserve QCI=2 for mobile TV in the network. This would not be possible in the solution described in 3GPP TR 23.886v0.3.1, as the detection of a video call would wrongly assume that the mobile TV video relates to a video call.
Note that this problem is not specific to video calls, but to any type of session where more than one bearer is required for the session.